This page last changed on Apr 13, 2009 by kanna.

Present: Tom, Thom, Angel, Frederic, Kanna

Synopsis of issues from going to seawas summarized in an email note on the autonomy mailing list. It revolved around:

  1. Email gateway issues with binary sbd messages getting stripped.    [Hans/Pat/Frederic]
  2. Shutdown of the autonomy computer. [Hans]
  3. Handshake between the NAL driver and T-REX. [Tom/Frederic]
  4. T-REX model bug to handle surfacing uncertainty. [Frederic]
  5. Matlab script bug. [Frederic]
  6. Continuing need to archive all sbd messages. [Hans]
  7. A more permanent way to ensure that the A3LA modem boots up correctly and to tackle issues with buffer garbage. [Hans/Thom]
  8. End-to-end testing of all the above. [Thom/Kanna]

Critical issues are #2 and #3. There is good understanding of what needs to be done for #3; the key issue is to work out a way to test the complete comm loop to and from shore as and when necessary.

#2 is more mysterious. Talking with Duane Thompson in the pm after the meeting shows no clear understanding of what went wrong at sea. Autonomy computer boot error was found when AUV was actually deployed (and not when on the deck as thought originally). This makes it more serious. Fundamentally, errors w/ h/w started occurring  when modem and autonomy computer was put on same power switch. As Frederic points out, last year a number of tests were carried out sending Iridium msgs. from sea.

For #3, the max msg. size is queried by T-REX and then msg. with that length is queued. We need to log max msg. length on the NAL driver side also for sanity. Problem Thu April 9th was that A3LA modem allows 1960 bytes/SBD msg. but hard-coded 1024 as byte length within NAL driver.

To test modem issues:

  •     test client pretending to be on the VCS
  •     from shore send email client (use Matlab code)

T-REX has a logging facility to log even the binary msg. But at sea (with modem connected) paradoxically this logging was turned off. This does not happen when on shore testing with Pseudo-Sim.

We do need a way to sync. when T-REX posts a message to the buffer and when the NAL driver actually sends out the msg. This is for validation on shore that what T-REX sent was actually communicated; conversely what the driver received, T-REX actually consumed as a goal.

There is a separate issue of when the modem is fired up, when there appears to be some initializing problem with junk in the buffer as found at sea. Tom believes this could be either an issue with sending binary data when the modem is expecting a text data or some configuration issue with expectation of what the data is likely to be and what is actually received by the modem. NAL A3LA has different user profiles. Could a confusion of the profile being the cause of the garbage when the modem fires up?

Worth investigating to buy an Iridium modem antenna for the roof of Bldg. B. Checked with Mark Chafee (who did the same for MOOS for Bldg G). To have a modem reception in Bldg B, need an antenna + modem and a RS 232 serial line from the modem to the lab. Approx cost ~ $1500.00

Document generated by Confluence on Feb 04, 2026 08:05